Manufacturers of semiconductors regard testing and evaluation processes as indispensable stages of their design and production operations. Semiconductors, also known as integrated circuits (IC), are electronic circuits that process, store, and move information. Operations associated with the production of semiconductors involve substantial investment of resources. Consequently, it is advantageous to verify IC designs prior to committing the designs to full scale manufacturing.
Accordingly, design verification is an important stage in validating an IC layout. One form of design verification involves one or more design rule checking (DRC) processes, which may be performed by design verification decks incorporating one or more design verification rules (hereinafter “design rules”) governing “permissible” physical layouts of, for instance, a full IC design, such as a full system on chip (SoC) design. Design rules are generally defined by a foundry, i.e., a semiconductor processing facility configured to manufacture SoC designs from, for example, silicon wafers. Design verification decks apply the design rules against the actual physical layout of a design to determine layout drawn errors, also commonly referred to as design verification violations, e.g., DRC violations or design verification errors. With the continuing decrease in IC feature sizes, design rules are becoming evermore complex and restrictive to ensure a suitably manufacturable and operable end product. Design rules, however, are typically conservative, and, as a result, are usually incrementally revised over time. Further, full SoC designs usually incorporate one or more blocks of intellectual property (IP), which may also be incrementally revised over time. This flux in design rules often necessitates revised design verification decks that include the revised design rules. Revisions, however, to the design rules and/or physical IP block designs may result in new true/false design verification violations being reported in association with existing physical IP block designs. These design verification violations may be classified, such as waived, for particular handling purposes during design verification operations, but DRC violation waivers are generally only authorized by the foundry. Although the term “waivers” will be used throughout this disclosure, waivers are to be regarded as illustrative and not as restrictive, and other types of design verification classifications are to be encompassed by this disclosure.
Most other areas of electronic design automation (EDA) tools have been steadily improving in terms of productivity in the design phase of an IC. Design verification tools, such as design verification tools to create and manage design verification violation waivers, have been less productive, resulting in increased design cycle schedules and a boost in the consumption of valuable resources. Accordingly, creation and management of design verification violation waivers is becoming increasingly more important, especially with regard to the automation of design verification operations. More specifically, automated design verification waiver flows would not only enable IC designers to significantly reduce their time to resolve false design verification violations, but would also enable IC designers to reduce time to tapeout and manufacture.
In addition, checksums are employed as a way of uniquely defining a drawn layout with a unique numeric number. An IP_Checksum refers to a single checksum that uniquely identifies an IP block geometric layout by a checksum. A Cell_Checksum is similar to an IP_Checksum and is applicable where the IP is a library of cells, and each cell can have its own unique checksum. A Polygon_Checksum is a checksum for a single polygon. If one vertex moved in a layout, the resulting checksum will be different. The algorithm for a checksum can be proprietary to the specific EDA vendor. Therefore, layout DRC error waiver description files, which are provided in graphical data system (GDS or OASIS) format and contain such checksums (that uniquely provide a fingerprint of the total layout of the DRC waiver polygons for that IP block), are EDA vendor specific.
A need, therefore, exists for methodology enabling efficient creation and management of design verification waivers. There exists a particular need for methodology enabling efficient creation and management of design verification waivers in batch mode processes that are capable of handling multiple revisions of design verification rules and/or multiple revisions of physical IP block designs. A further need exists for methodology for creating and providing to users waiver description files which do not include checksums and have a generic format.